System automation includes having a desired runtime behavior of Information Technology (IT) that can be described in a formal way and that an automation decision instance, an automation engine, performs tasks on behalf of a human operator. The focus of Tivoli® System Automation is on automating the availability of Information Technology (IT) resources. High availability is in particular relevant for mission-critical application systems, such as banking environments. IT resources are started and stopped in different scenarios, either intentionally for maintenance purposes or unintentionally when failures occur.
An automation domain or automation cluster is the scope of a set of IT resources that are automated by an automation manager. Typically, a cluster of server nodes is hosting these IT resources and there is one policy describing the desired automation behavior for the set of IT resources.
Conventional automation software is typically script-based or policy-based. Scripts are typically written by a system specialist and implement a desired automation behavior. Policies use an abstract configuration description of the IT resources that are used to run the application. A policy-based automation solution can allow performing a configuration change more easily than a script-based automation system.
The IT resources can comprise application software components, operating system software components, and hardware components to run the software components. Enterprise application environments are typically heterogeneous using diverse platforms, such as the IBM® Mainframe System z® operating system, Unix® operating system, and Windows® operating system, which are usually maintained by different system operators and require different skills, administration tools, and programming languages.
Resource groups are composed of members that share a common automation goal and are managed as one unit. Resource group members can be resource references, choice groups or other resource groups, thus allowing an arbitrary level of nested groups. The IT resources in the automation domain are in the automation scope and therefore managed by an automation engine. Therefore, these resources can also be called managed resources.
Automation can be goal-driven. This means that the automation manager knows the automation goal for each resource. The automation goal is typically represented by a goal request on the resource defining a “desired state” of the resource that the automation manager pursues. Possible desired states of the resource are, for example, “online” and “offline.” When the desired state is “online”, the automation manager is trying to keep the resource “online.” In the case of the desired state being “offline”, the automation manager is trying to maintain the “offline” state of the resource. An “observed state” describes a current state of an actual resource. If the observed state is “online”, the resource is running. If the observed state is “offline”, the resource is stopped. The differences between the “desired state” and the “observed state” are reflected in a so-called “compound state”, which indicates whether the resource works as desired or whether not because problems may have occurred. For example, the “compound state” may indicate “ok” when the desired state and the observed state are the same, and the compound state may show “warning” or “error” when both states are different. A so-called “operational state” provides additional information about the “compound state.”
The automation manager is further aware of relationships between the resources that are defined in an automation policy. Examples for relationships are “StartAfter”, “StopAfter”, “ForcedDownBy”, and “DependsOn.” If a first resource receives a goal request for the desired state to be “online” and has a “StartAfter” relationship with a second resource, the second resource will be started before the first resource. The automation manager ensures that the resource is only started or stopped when it has determined that any relationship conditions defined for the resource in an automation policy are fulfilled and no higher priority goal requests sent to the automation manager are waiting to be executed.
In an event-driven system automation, the automation engine of the automation manager subscribes to change events of the resources of the automation domain. The resources notify the subscribing automation engine in the case of a state change by sending a change event to the subscriber.
The Semantic Web provides a common framework that allows web data to be shared and reused across application boundaries. It is a collaborative effort led by the World Wide Web Consortium (W3C) to make information in the World Wide Web (WWW) accessible to machines and web agents by enrichment of web data with semantic information. The W3C standardizes the following technologies in a Semantic Web stack. The basis technologies are XML and URI. An Extensible Markup Language (XML) is a general-purpose specification for creating custom markup languages. A uniform resource identifier (URI) is a string of characters used to identify a resource on the Internet.
On top of XML and URI, a Resource Description Frameword (RDF) provides a general method for conceptual description or modeling of information that is implemented in web resources. The RDF data model is based on an idea of making so-called RDF statements about resources, in particular, web resources, in the form of subject-predicate-object expressions. These expressions are also known as RDF triples in Semantic Web terminology. The RDF uses URIs to semantically describe the RDF statements. The subject is an URI that denotes the resource being described, and the predicate is an URI that denotes a trait or an aspect of the resource, which is either an object property or a datatype property. The object property links a resource represented by the subject to another resource represented by the object, which is also called a relationship between the respective resources. The datatype property links a resource represented by the subject to a data value represented by the object. The RDF is defined in an abstract model with several serialization formats, and so the particular way in which the triple is encoded varies from format to format. A single RDF statement can be represented by a graphical notation such as a conceptual graph. A collection of RDF statements may be displayed by an RDF graph.
A Web Ontology Language, in the literature named as OWL Web Ontology Language (OWL), further provides a model for specifying the semantics of the RDF elements in form of an ontology that is itself serialized in the RDF. Therefore, metadata describing the ontology is presented in the same format as the data representing the RDF statements and stored together in a knowledge base. The OWL is a family of knowledge representation languages for authoring ontologies and is endorsed by the W3C.
In computer and information science, an ontology is a formal representation of a set of concepts (classes) within a domain, individuals (instances) of the concepts, attributes (aspects, properties) of the concepts, and relationships between the concepts (classes). The ontology describes all the concepts, relationships, properties and rules that are relevant for a certain reasoning scope. For a Semantic Web based system automation, an ontology can describe all concepts that may occur in its automation domain. Reasoning on top of these layers, that is, using the ontology to infer further RDF statements, leads to a logic layer.
The Semantic Web typically makes an Open World Assumption (OWA). Knowledge about any resource can be spread all over the world. Everybody may add even wrong or inconsistent information to the Semantic Web. Therefore, a web agent is aware that it has to deal with incomplete, partially false or contradicting knowledge. Since the Semantic Web is based on the Open World Assumption, there are no mechanisms to ensure the constraints of ontologies. These constraints may be cardinality restrictions or datatype restrictions. With the OWA, a web agent can never assume that it has retrieved all RDF statements about a certain resource since further descriptions of the resource may exist in a part of the Semantic Web that is currently not accessible or was not found.
Furthermore, the Semantic Web agents assume that the knowledge of the domain is static and does not change over time. In the conventional Semantic Web, the web agent comprises a knowledge base which is never updated since the information provided in the Semantic Web is assumed to be static truth which does not change, especially not during a lifetime of a web agent. When resource changes occur, the conventional Semantic Web agent would not recognize the changes since the Semantic Web provides no mechanism for their recognition. A rebuild of the complete knowledge base is triggered manually to update changes. The lifetime of a web agent is assumed to be much shorter than the data provided in the Semantic Web.
A semantic reasoner, a reasoning engine, a rules engine, or simply, a reasoner, is an application that is able to infer logical consequences from a set of asserted facts (axioms). Reasoning means applying a set of inference rules to a set of knowledge to generate more knowledge. The inference rules are commonly specified by means of an ontology language and often a description language. Inference commonly proceeds by forward chaining and backward chaining. Forward chaining is data-driven. The forward chaining can start with the available data and work forward from an antecedent or rule head (if-clause) to a consequent or rule body (then-clause) of each inference rule to extract more data until all statements are inferred that are valid. Backward chaining is goal-driven. The backward chaining can start with a list of goals and work backwards from each consequent (then-clause) to a respective antecedent (if-clause) to see if there is data available that will support any of these consequents. Tabled backward chaining can store all previously computed matches to goals and use the recordings when trying to resolve future requests to the same goals. The memorized goals are commonly discarded when the inference metadata model is updated. The rule evaluation is monotonic when the amount of data is always increasing with the evaluation operations. Some commonly used solutions are “Jena—http://jena.sourceforge.net/, Pellet—http://pellet.owldl.com/, Bossam—http://bossam.wordpress.com/”, etc.
Many reasoners use the Semantic Web Rule Language (SWRL) as a description language for the rules. Jena uses its own rule language, which is more restricted than SWRL. The reasoning strategy differs between the frameworks, but is mainly some sort of forward chaining, tabled backward chaining or hybrid solutions. Available rule systems have a flat view on rules. Rules are not organized in a hierarchical system. All rules are considered all the time. To test if a rule has to be evaluated, all the rules are considered in forward and backward chaining Since the rules are not organized in a hierarchical system, and there is no predetermined evaluation strategy in conventional Semantic Web reasoners, a change of the knowledge base, that is, adding one RDF statement, makes it necessary to apply all rules to all RDF statements in the knowledge base in order to perform forward chaining. The rules can contain variables. A variable binding is a replacement of every occurrence of a variable with one specific resource or one specific data value. A rule is satisfied if bindings of rule variables to respective parts of RDF statements are found in the knowledge base, where the parts of an RDF statement are subject, predicate, and object. Therefore, if one RDF statement is added to the knowledge base, all possible variable bindings have to be tested. That is, all statements of the knowledge base have to be applied to all rules in forward reasoning. And since a side-effect of satisfied rules is adding further inferred RDF statements to the knowledge base, the complexity of a reasoning algorithm is often exponential.
Conventional reasoners of the Semantic Web are monotonic. That is, these reasoners only add further inferred RDF statements to the knowledge base. Assumption is made that truth does not become invalid, so there is no need to remove RDF statements from the knowledge base while reasoning over resource descriptions that do not change over time. Reasoning is non-monotonic when additional information may lead to reasoning that changes the knowledge base in such a way that the amount of valid statements decreases. New or updated statements may result in the fact that rule conditions that have been satisfied previously are not satisfied any more. A satisfied rule may lead to an explicit removal of previously inferred RDF statements. Furthermore, if a rule is no longer valid, the statement that was derived from the rule becomes also invalid and has to be removed. In the case of non-monotonic reasoning, the outcome of the reasoning depends on the sequence in which the rules have been applied. In non-monotonic reasoning systems, the behavior of the reasoner becomes non-deterministic if there is no rule evaluation strategy that specifies the order in which rules are evaluated. This is, however, unsuitable for dynamic automation domains, such as System Automation, where the automation engine takes the role of a web agent and lives much longer than the descriptions of the IT resources that are managed and that do change their state over time.
Monotonic reasoners cannot handle dynamically changing resources. Since these reasoners do not know the interdependencies between the RDF statements in the knowledge base (that is, which RDF statement was inferred on the basis of which other RDF statements), the reasoner would have to revoke the entire set of inferred RDF statements in the knowledge base, resulting in a complete re-calculation.
The Open World Assumption, the static domain assumption, and the monotonicity of reasoning are design issues that restraint the applicability of Semantic Web technologies to a wide application area, namely dynamic, non-monotonic environments like System Automation, where resources change within a lifetime of the automation manager.